\section*{Run 1}
\subsection*{Modules to decompose}
The module we are going to decompose in this run is the entire ReMeS module.

\subsection*{Choose architectural drivers}
\begin{itemize}
\item P1: Timely closure of valves
\item UC7: Send trame to remote device
\item UC9: Notify customer
\item UC13: Send Alarm
\end{itemize}

We chose to start with P1 as the driver for the first ADD run. P1 is a high priority requirement. We find that P1 covers a lot of important functionality we can use to decompose the system. Not only communication, but alarm handling and also database interaction is required with P1. The use case related to P1 are UC7, UC9 and UC13.

\subsection*{Choose architectural patterns}

Performance tactics:
\begin{itemize}
\item Resource management: obviously increasing the available resources is a logical solution for this requirement, but this is more a hardware solution than an architectural solution. Adding new hardware is not the only solution, therefore we chose to introduce concurrency. When multiple request can be handled in parallel, the blocked time can be reduced, resulting in a faster request handling.
\item Resource arbitration: A dynamic priority scheduling algorithm with earliest deadline first seems to be the best choice in our opinion. This way, gas alarms have the highest priority, followed by water and then by power. Gas has a deadline of only 10 seconds so most of the time it will have the highest priority. With dynamic scheduling starvation is not possible, because deadlines always get shorter and the shortest deadline will always be chosen first.
\end{itemize}

Patterns
\begin{itemize}
\item Active Object (P1): Since P1 needs concurrency and a scheduling algorithm the active object pattern seems to be a logical choice as a pattern. Not only will the alarms be handled concurrently, but also according to a dynamic scheduling principle.
\end{itemize}

\subsection*{Modules}

\begin{itemize}
\item Incoming Communication Module: This module is responsible for the incoming trames. Not only will it schedule the different trames according to their priority, but it will also route the different trame messages to the different relevant components in the system. This component will be build according to the active object pattern.
\item Outgoing Communication Module: This module is responsible for sending trames over the right channel to the remote modules, and for sending notifications to the customer. Because it needs to know what channel is used for what remote module, it has a connection to the Main DB component to be able to request the needed data.
\item Alarm Handler: The alarm handler component is responsible for handling the alarm trames. It will use the Command Sender component to initiate the closing of the valve and it will tell the notification handler to notify the customer of the alarm.
\item Notification Handler: The notification handler is in charge of the notifications to customers, emergency services and ReMeS operators. For now 2 interfaces are presented. One interface is to allow the alarm handler to make an alarm notification to the customer and if necessary to the emergency services. The second interface will give other components the possibility to notify a ReMeS operator of possible issues. For now the only possible issue is that the remote module does not confirm the closing of his valve. This component is connected to the Notification DB and thus knows how to contact customers. Another notification that will be added is the notification of anomalies. This will be added in following ADD runs.

\item Command Sender: For now this component will be used to send acknowledgments for trames, actuate valves and process the confirmation of this actuation. This module has a connection with a database component, because it needs to know what remote module is connected to what valve. This component will later in the ADD runs get more functionality. It is the central component that gives all other components the possibility to send commands to the remote module or remote valve. All these commands should return a confirmation from the remote module. By centralizing these commands, all the confirmation can be stored in one place and problems with confirmation trames can be handled in this component.
\item Notification DB: The Notification DB component holds the notification data (e.g. phone number, email address) needed to send alarms to the customer. We decided to make this database independent from the Main DB, because the request from this database may not interfere with requests from the Main DB (e.g. storing and retrieving measurements, requesting consumption profiles, ...). In this way, notifications still can be send(e.g. notifying a ReMeS operator when the Main DB fails).
\item Main DB: The Main DB for now only reads data. Of course this will be complemented in the next ADD runs. This DB at least keeps track of user data, measurement data and remote module/valve data. It is split up from the Notification DB to have no interference between the two.
\end{itemize}

\begin{figure}
  \centering
    \includegraphics[width=\textwidth]{addRuns/ADDRun1.pdf}
  \caption{Run 1: Level 2 decomposition of the ReMeS system}
  \label{addRun1}
\end{figure}

%Overzichtsschema invoegen

\subsection*{Define interfaces}

\begin{center}
    \begin{longtable}{ | p{4cm} | p{3,5cm} | p{7,5cm} |}
    \hline
    Component & Interface & Operations \\ \hline
    Incoming Communication Module & iIncomingModule & \begin{itemize} \item \textbf{receiveData(Data d)} \end{itemize}  \\ \hline
    Alarm Handler & iAlarmHandler & \begin{itemize} \item \textbf{processAlarmTrame(Trame t)}  \end{itemize}  \\ \hline
    Notification Handler & iNotificationHandler & \begin{itemize} \item \textbf{sendAlarmNotification(Module m, Details d)} \item \textbf{sendIssueNotification(Details d)} \end{itemize} \\ \hline
    Command Sender & iCommandSender & \begin{itemize} \item \textbf{actuateValve(Module m)} \item \textbf{processConfirmTrame(Trame t)} \item \textbf{sendAck(Module m, Trame t)} \end{itemize} \\ \hline
    Notification DB & iNotificationDB & \begin{itemize} \item \textbf{readNotificationData(Module m)} \end{itemize}  \\ \hline
    Main DB & iMainDB & \begin{itemize} \item \textbf{readData(Query q)} \end{itemize} \\ \hline
    Outgoing Communication Module & iOutgoingModule & \begin{itemize} \item \textbf{sendNotification(Notification n)} \item \textbf{sendCommand(Command c)} \end{itemize} \\
    \hline
    \end{longtable}
\end{center}

\begin{figure}[h]
  \centering
    \includegraphics[width=\textwidth]{addRuns/level2.png}
  \caption{Run 1: Interfaces for level 2 decomposition of the ReMeS system}
  \label{level2}
\end{figure}

\subsection*{Verify and refine}
If we look at the different components we created in the first run, we can see that we have a lot of components all with different functionality. With all these components only the top level decomposition is visible. It still remains unknown for these components how the internal functionality works. The next ADD runs will elaborate more on this. If we take a look at P1, UC7, UC9 and UC13 we have implemented the ability to:
\begin{itemize}
\item accept and process alarm trames.
\item send alarm notifications to the customer.
\item send commands to close valves according to the alarm trames.
\item notify a ReMeS operator of a problem with confirmation trames.
\end{itemize}
However, some functionality is not yet implemented and needs to be refined more. These are the attention points to watch for in the next ADD runs:
\begin{itemize}
\item Priority scheduling for the incoming trames needs to be implemented. A scheduler will be added in the next ADD run.
\item In combination with the priority scheduling the Incoming Communication Module needs a way to route the trames to the correct component.
\item Priority scheduling for the outgoing trames needs to be implemented. A scheduler will be added in the next ADD run.
\item In the Command Sender a record/overview of send commands (e.g. close valve) must be maintained. This record should be used to know when confirmation trames from the remote modules are expected. When a remote module fails to return a confirmation trame, a ReMeS operator should be notified.
\item The alarm trames cannot yet be stored in the database, so this is something that must be adapted in the next ADD runs.
\end{itemize}
UC9 seems to be covered. Since there is not yet the possibility to write data to the database, both UC7 and UC13 need to be refined more.

\paragraph*{Requirements that are now completely covered:}
\begin{itemize}
\item \textbf{UC9: Notify customer}
\end{itemize}

\subsection*{Remarks}
\begin{itemize}
\item The alarmNotification interface notifies both the customer as well as the emergency services (if required)
\item If for some reason there are a lot of notifications to be handled with certain priorities the Notification Handler component can be extended with a buffer and a scheduler. For now this is not required so this component will not be elaborated on in next ADD runs, with the exception of adding new interfaces to handle other notifications.
\end{itemize}
